Most vetting advice for software development companies is written by business people for business people. It focuses on proposals, communication style, and case studies.
That's useful. But it misses a whole category of signals that only someone who writes code would think to look for.
I've been a developer for ten years, I've worked at agencies, and I've seen how the sausage gets made from both sides of the client relationship. Here is the vetting process I would run if I were a non-technical founder hiring someone to build my product.
Start With What You Can See Publicly
Before the first call, do your homework.
Check their GitHub. Any development company worth their rates has a public GitHub presence. Look at their open source contributions, their public repos, and the quality of their documentation. Code that is poorly commented, inconsistently structured, or full of outdated dependencies is a preview of what they'll produce for you.
Check their client products. If they list products they've built on their website, use those products. How is the performance? Do they feel polished? How does the sign-up flow work? Are there obvious bugs? You don't need technical knowledge to evaluate whether a product works well as a user.
Look up their team on LinkedIn. How senior are the engineers they employ? How long have they stayed at the company? High turnover in development teams is a strong signal of internal dysfunction that will affect your project.
Check their reviews on third-party platforms. Clutch, G2, and Google Reviews all contain client feedback. Look specifically for patterns in the negative reviews. Every company has some negative reviews. The question is what the problems were and how the company responded.
The Technical Signals You Can Actually Evaluate
You don't need to know how to code to evaluate these, but you do need to ask about them specifically.
How they handle security
Ask: "What's your standard approach to security in production applications?"
A good answer includes specific things: HTTPS everywhere, secure environment variable management, input validation to prevent injection attacks, authentication with industry-standard libraries rather than custom implementations.
An answer that's vague or generic ("we take security seriously") is a red flag. Security is concrete and specific. If they can't describe their practices in detail, they probably don't have rigorous ones.
How they manage code quality
Ask: "What does your code review process look like?"
Pull requests, peer review before merging, automated testing, and linting are baseline practices in any professional team. If they don't have a structured code review process, the code that ends up in your product has not been checked by a second set of eyes.
What they do about documentation
Ask: "What documentation do you produce as part of an engagement?"
You want to hear about inline code comments, README files for each major component, an architecture overview, and a deployment runbook. Documentation is how you ensure that future developers, whether from another company or your own in-house team, can work on the product without starting from scratch.
How they test
Ask: "What's your testing strategy for a project like this?"
Unit tests, integration tests, and end-to-end tests are the three layers of a solid testing pyramid. A team that doesn't write tests is leaving you with a product that will break unexpectedly every time someone changes something. Tests are also how you validate that the product does what it's supposed to do.
What their deployment process looks like
Ask: "How do you handle deployments, and what monitoring do you set up for production?"
Good teams use automated deployment pipelines, not manual FTP uploads or copy-paste to servers. They set up error monitoring (tools like Sentry), performance monitoring, and alerting so that when something breaks in production, someone is notified immediately.
The Questions That Reveal Character
Technical competence matters. So does how a team behaves when things go wrong.
"Tell me about a project that didn't go well. What happened and how did you handle it?"
Any team that claims all their projects go well has either done very few projects or isn't being honest with you. What matters is not whether problems occur, but how the team responds when they do.
"What happens if you're building something and you realize the approach isn't working?"
A professional team has a process for surfacing problems early, escalating to the client, and proposing alternative approaches. A team that doesn't have an answer to this question will either hide problems until they become crises or change direction without telling you.
"Can I talk to a client who had a difficult experience with your team?"
This question makes most teams uncomfortable, and that's partly the point. A team confident in how they handled past difficulties will give you a name. Their willingness to do this tells you a lot.
The Portfolio Evaluation Nobody Does
Most founders look at portfolios to evaluate design quality. Here's the question you should actually be asking: can you contact the founders of these products and ask them about the experience?
Not testimonials. Actual conversations. Ask specifically:
- Did the project come in on budget and on time?
- What did you have to fix after launch that should have been caught before?
- Would you work with them again? Why or why not?
Past clients who genuinely had a good experience will be willing to have this conversation. The ones who had problems will either decline or give you very telling hedged answers.
Red Flags That Are Easy to Miss
They are resistant to giving you code access. You should have access to your own codebase at all times, throughout the engagement. A team that controls access to the repository has leverage over you that you should not allow.
They propose to host the product on their infrastructure. Your product should live on your own cloud accounts (AWS, GCP, Vercel), not theirs. If they host it, they have leverage over you at contract renewal time.
They can't explain their pricing. If you ask them to break down a quote by feature or phase and they can't do it, the number was not based on careful estimation.
They promise a fixed price without a discovery phase. Any team that can quote you a fixed price on a new product without understanding it in detail is either guessing or planning to add scope change orders throughout the project.
FeatherFlow is a studio that welcomes this level of scrutiny. The best teams do, because their process actually holds up to it.
What Good Looks Like
By the end of a proper vetting process, you should have:
- Spoken with at least two past clients directly
- Reviewed live products they've shipped
- Had a detailed technical conversation where they described their security, testing, and deployment practices specifically
- Received a proposal that breaks down cost by scope item or phase
- Seen a contract that assigns all IP to you
If any of these are missing, you don't have enough information to make a sound decision with your money.
Frequently Asked Questions
How long should vetting a development company take?
At least two to three weeks if you're making a significant investment. This includes an intro call, a discovery conversation, reference checks, proposal review, and follow-up questions. The founders who rush this because they're excited to get started are the ones most likely to regret it.
Should I do a paid trial project with a development company?
A small paid trial on a specific, bounded component is an excellent way to evaluate a team before committing to a full engagement. This costs a few thousand dollars and gives you real data on their communication, quality, and reliability. It's worth it for a company you're not certain about.
What does a fair development contract look like for a non-technical founder?
Essential elements: IP assignment to you as work is created, confidentiality provisions, clear payment milestones tied to deliverables (not just time), a change order process for scope changes, and provisions for what happens if the engagement ends early. A startup lawyer can review a contract for a few hundred dollars and it's worth doing.
Is it a red flag if a company uses offshore developers?
Not inherently. Many excellent development companies operate across multiple time zones with offshore talent. The question is whether the senior leadership and communication is accessible, whether the code quality holds up, and whether past clients had positive experiences with the working relationship.
How do I evaluate technical proposals when I'm non-technical?
Ask the team to walk you through the proposal verbally. A good team can explain their technical choices in plain language. Ask why they chose a particular technology stack. Ask what the alternatives were and why they rejected them. You don't need to evaluate the choices technically. You're evaluating whether they can explain their reasoning clearly, which is a reliable proxy for whether they thought carefully.